set TLS option CURLSSLOPT_REVOKE_BEST_EFFORT #115
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The Windows native TLS backend (Schannel) makes synchronous certificate revocation checks against a CRL server. For users behind a firewall, this server may be unreachable, causing the TLS connection to fail. The CURLSSLOPT_REVOKE_BEST_EFFORT option addresses precisely this situation, configuring Schannel to make a best effort revocation check but allowing the connection if the CRL server cannot be reached, as long as the certificate isn't already known to be revoked. This behavior matches the default revocation checking behavior on macOS (asynchronous best effort) and is strictly more secure than Linux where no CRL checking is done. Since the typical advice in such situations is to disable TLS host verification entirely, this is an improvement in that with this option, so long as the client's system CA roots are configured correctly, host verification will work and at least local MITM attacks are prevented.
StefanKarpinski
force-pushed
the
sk/tls-revoke-best-effort
branch
from
34deb3f to
d34b152
Compare
|
I'm just going to merge this and hope that it improves things since it seems unlikely that anyone in this situation (Windows & strict firewall) will test this change. 🤞🏻 |
StefanKarpinski
added a commit
that referenced
this pull request
May 4, 2021
The Windows native TLS backend (Schannel) makes synchronous certificate revocation checks against a CRL server. For users behind a firewall, this server may be unreachable, causing the TLS connection to fail. The CURLSSLOPT_REVOKE_BEST_EFFORT option addresses precisely this situation, configuring Schannel to make a best effort revocation check but allowing the connection if the CRL server cannot be reached, as long as the certificate isn't already known to be revoked. This behavior matches the default revocation checking behavior on macOS (asynchronous best effort) and is strictly more secure than Linux where no CRL checking is done. Since the typical advice in such situations is to disable TLS host verification entirely, this is an improvement in that with this option, so long as the client's system CA roots are configured correctly, host verification will work and at least local MITM attacks are prevented. (cherry picked from commit 4e87640)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Windows native TLS backend (Schannel) makes synchronous certificate revocation checks against a CRL server. For users behind a firewall, this server may be unreachable, causing the TLS connection to fail. The
CURLSSLOPT_REVOKE_BEST_EFFORToption addresses precisely this situation, configuring Schannel to make a best effort revocation check but allowing the connection if the CRL server cannot be reached, as long as the certificate isn't already known to be revoked. This behavior matches the default revocation checking behavior on macOS (asynchronous best effort) and is strictly more secure than Linux where no CRL checking is done.Since the typical advice in such situations is to disable TLS host verification entirely, this is an improvement in that with this option, so long as the client's system CA roots are configured correctly, host verification will work and at least local MITM attacks are prevented.
See this discussion where several Windows uses behind firewalls reported this issue.